Skip to content

docs(acp): correct subscription auth for codex-acp and claude-agent-acp - #4623

Open
asatire1 wants to merge 1 commit into
block:mainfrom
asatire1:docs/acp-subscription-auth
Open

docs(acp): correct subscription auth for codex-acp and claude-agent-acp#4623
asatire1 wants to merge 1 commit into
block:mainfrom
asatire1:docs/acp-subscription-auth

Conversation

@asatire1

@asatire1 asatire1 commented Aug 3, 2026

Copy link
Copy Markdown

The buzz-acp README tells operators they need API keys for both Codex and Claude. Neither is true against the current adapters.

Codex. The section said OPENAI_API_KEY was "required — use an OpenAI API key, not a ChatGPT subscription", and described a 426 Upgrade Required WebSocket fallback. codex-acp 1.1.9 reuses the Codex CLI's stored login at ~/.codex/auth.json, and reads CODEX_API_KEY/OPENAI_API_KEY only when the api-key auth method is selected.

Claude. The section said to export ANTHROPIC_API_KEY. claude-agent-acp 0.64.2 advertises claude-ai-login ("Claude Subscription") alongside console-login ("Anthropic Console (API usage billing)"). It does keep its own credential store rather than inheriting an existing Claude Code login, so the one-time --claudeai command is now shown explicitly rather than left implicit.

Neither claim held because buzz-acp injects no auth of its own — AcpClient::spawn uses tokio::process::Command with no env_clear(), and gives inherited parent env precedence over anything Buzz sets, so the adapter's own login applies. This is documentation only; no behaviour changes.

Testing

  • Drove each adapter through initializesession/newsession/prompt with ANTHROPIC_API_KEY, OPENAI_API_KEY, CODEX_API_KEY and CLAUDE_CODE_OAUTH_TOKEN removed from the child environment. Both completed a turn with stopReason: end_turn.
  • End-to-end through buzz-acp against a local relay: agent replied to an @mention in-channel, with zero *_API_KEY vars in the harness process environment (ps eww).
  • Versions: codex-acp 1.1.9, claude-agent-acp 0.64.2.

Note on #4611

#4611 proposes launching Claude ACP adapters with an allowlisted environment and a disposable home, which would deliberately stop this credential inheritance. If that lands, the Claude auth note here needs revisiting — happy to fold this into that PR instead if the maintainers prefer.

The Codex section said an OpenAI API key was required, "not a ChatGPT
subscription", and described a 426 WebSocket fallback. That is no longer
how the adapter behaves: codex-acp reuses the Codex CLI's stored login at
~/.codex/auth.json, and reads CODEX_API_KEY/OPENAI_API_KEY only when the
api-key auth method is selected.

The Claude section told operators to export ANTHROPIC_API_KEY, which is
also unnecessary — claude-agent-acp advertises claude-ai-login ("Claude
Subscription") alongside console-login ("Anthropic Console (API usage
billing)"). It does keep its own credential store rather than inheriting
an existing Claude Code login, so the one-time --claudeai command is now
shown explicitly.

Neither claim was true because buzz-acp injects no auth of its own:
AcpClient::spawn uses tokio::process::Command with no env_clear(), so the
adapter's own login applies.

Verified against codex-acp 1.1.9 and claude-agent-acp 0.64.2 by driving
each adapter through initialize -> session/new -> session/prompt with
ANTHROPIC_API_KEY, OPENAI_API_KEY, CODEX_API_KEY and CLAUDE_CODE_OAUTH_TOKEN
removed from the child environment. Both completed a turn with
stopReason: end_turn. Also confirmed end-to-end through buzz-acp against a
local relay: the agent replied to an @mention with zero *_API_KEY vars in
the harness process environment.

Signed-off-by: asatire1 <asatire@gmail.com>
@asatire1
asatire1 requested a review from a team as a code owner August 3, 2026 21:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant